寫了一週的文章之後，意外收到不少反饋！默默覺得工程師們真的都好辛苦啊QQ
工程師這種生物畢竟就是太過認真可愛，比較逆來順受一點（抱大腿）
所以大部分的工程師，都點了不少通靈技...

不過～我來參加鐵人賽，肩上背負的使命或許也包括「想為工程師們發聲」吧！
（我想工程師們推我下這個坑肯定是對我有所期待吧！？對吧？對吧？）（並沒有。）

好吧。自作多情的設計師要開始正文了（拭淚）...

除了在「與工程師的協作之路-工具篇（Zeplin）」中介紹的溝通工具，其實更重要的是實際討論與企劃書本身！

當然，業界不是所有的企劃書都那麼完整。
會 照書養 的，即使有照辦的少數，大部分都是一個對現實來說極度理想的狀態...（就像亂世出包青天那樣）

理想與現實落差總是有點大的...這點不只是在工程師角度，設計師也同樣感同身受，但是繼續寫下去我可能會 被公司吉 ...還是來寫點看起來很規矩的教學文吧！

產品核心

一個產品，最重要的是「核心宗旨」。

你的產品核心概念是什麼，決定了往後每個決策與走向，甚至能夠滲透到細節的決議～
所以核心宗旨絕對不會是萬人受用或是老少咸宜（又不是什麼營養口糧之類的），這類的只能當作一個「目標」，並不能被當作「宗旨」！
宗旨是更能夠貫徹整個產品的一個中心思想。只要團隊間對這個思想有一定的共識，溝通起來就會更有效率！

User Story

有了一個核心宗旨之後，我們就可以開始進行近一步的討論了！
查詢一下wiki你會看到他這樣說明：

In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. They are often recorded on index cards, on Post-it notes, or in project management software. Depending on the project, user stories may be written by various stakeholders including clients, users, managers or development team members.

User stories are a type of boundary object. They facilitate sensemaking and communication, that is, they help software teams organize their understanding of the system and its context.

大概的意思，總而言之就是說，用戶故事是基於用戶的觀點來寫的，用以提高共識和作為溝通使用，團隊中大家都可以來寫！

User Story是針對這項產品的使用者做一個比較具體的描述，例如：在職媽媽、朝九晚五的小資女...等等這類的形容詞搭配角色來述說一個故事！藉由這些故事，去推敲使用者可能有什麼習慣、哪些需求是他們首要的痛點。
有了這些故事，在發想產品時有遇到任何感到瓶頸、無法想得透徹的時候，試著帶入這些角色，你將能注意到原本看不見的東西...（不是阿飄！）

那麼，這和 與工程師的協作 有什麼關係？

PM「企劃書寫好了，請大家各自執行作業！」
Designer「請問...這是針對哪樣的客群呢？」
PM「有網路的都可以用！」
RD「這裡...這樣做真的好嗎？」
PM「你先開發看看再來討論！」

發現了嗎？
以上範例只有PM本身可能知道方向，對設計師和工程師來說，其實處在一個 不知自己為誰而做 的狀態。

這時候如果沒有足夠的中心思想與對使用者的描述，其實PM自己也容易遇到瓶頸，這可能造成朝令夕改、浪費資源的情況發生！也會使執行者感到薛西佛斯（對，又是他）

執行者不只是執行者

任何團隊，只要越能凝聚共識，就越能把產品做好！
最早以前的開發方式，執行者在拿到企劃書之前，對即將開發或設計的內容幾乎不了解，就算拿到企劃書也只能從頭理解起，但每個人對於一段話、一個故事、一個需求能夠理解的深度和含義絕對都不同，這樣非常有可能造成：

設計拿到，去找企劃討論一番；
工程拿到設計稿，去找設計討論一番，接著可能又協同設計去找企劃討論一番；
接著設計也要改、工程也要動了，但 時程已經快到了 呀！
企劃書還在難產中，只好壓縮開發時間了...

反覆不斷確認甚至翻盤，這都是很常有的事情...（以上還沒計入無限輪迴地獄）
甚至企劃和設計好不容易達成共識之後，工程只能回句：這沒辦法做。
這下子工程師又要被貼標籤了...

邀請設計師與工程師參與前期討論吧！

承上，執行者不只是執行者，使用者體驗必須是一種文化！
以使用者角度作為任何一個細節的發想立場，將能使你的產品更臻完美～

．設計師

設計師必須了解「為誰而設計」、「團隊正在解決或遇到什麼問題」...
因為畫面是產品接觸使用者的第一個門面，也直接影響使用者體驗！不了解這些，別說是解決問題，連一些基本該注意的細節都無法顧及！

強烈建議發想期就可以找設計師一起加入 ！越了解使用者，設計師越能發揮得更好！

．工程師

在團隊中，最了解技術的就是工程師了！
概念發想時工程師可加可不加（有些工程師對瞭解使用者也很熱衷，有些則是純技術狂熱者，務必尊重每位工程師的適性發展），但要開始討論架構的時候，請 一定 要邀請工程師加入！

就像一夥人出團去打怪，路上缺了HP藥，大家千辛萬苦的採集挖坑想取得補品，殊不知法師唸唸咒語大家就回血了，前面都是白忙一場。

前期討論這個產品可能有哪些功能想做、邏輯可能是什麼的時候，找工程師進來協助發想吧！
他們絕對會告訴你哪些功能已經有哪些套件可以使用、其實有更快的方式能夠解決這些問題。

其實本來只是想稍微介紹一下User Story的名詞定義與產品發想時的使用方式，好像不小心囉唆了起來

但願眾設計師與工程師們在開發的漫長道路上，能夠每天心平氣和、充滿目標與希望（？）～
那麼，下次見～